前言

今天要來聊一件與開發相關，但有時候並不常實際感受到他的東西，叫做架構模式Architectural pattern。

除非你是有親手將產品完成從0到1的部分，不然通常進到公司時，你不太會發現公司是使用什麼架構模式在工作，且也不會參與到使用什麼架構模式開發的決策。

那到底什麼是架構模式?他又對開發有什麼影響?又有哪些常見的架構模式呢?

今天就會聊這些~那開始吧!

架構模式是什麼?

是一種決定系統如何被構築、彼此之間如何互動的一套規則~

Monolithic

被稱為單體或是單片架構，幾乎可以說是所有開發應用程式的預設模式。

因為從我不專業的角度來看，就是一個綜合所有功能的機器，不管你為了什麼原因希望強化某些功能，比如你希望強化A功能的處理速度，基本上都需要直接增加一整台機器，而不是那個單一功能。

比較定義化的說法是: 一個單一且不可分割的應用程式。

他的優點包括:

• 易開發: 不管在工具或是開發習慣上，對於不同功能的切換，以及組件支援的掌握都相對容易
• 易部署: 對於單一目錄的直接部署
• 易擴展: 單一應用程式直接平行擴展是可行的

當然也有一些缺點，而我認為這些缺點在大型化後顯得更為明顯，所以列出單體架構的系統開始龐大後可能的缺點:

• 開發複雜度: 因為code base的龐大，就算有良好的設計模式，也容易令人對於修改沒有信心
• 部署/擴展速度相對緩慢: 前面雖然提到過他易於部署，但反過來因為龐大後可能會讓部署的速度變慢，進而影響平行擴展的速度
• 新技術壁壘: 特別在針對不同的新語言時，會因為可能考慮重寫整個程式而作罷。

SOA

全名為service-oriented architecture，與其說他是一種技術，更不如說他是一種概念及原則。

他的概念是:

軟體的部分組件（呼叫者），可以透過網路上的通用協定呼叫另一個應用軟體元件執行、運作，讓呼叫者獲得服務

他的誕生來自於前面提到的monolithic，在一開始，開發其實是有邊界的、靜態的，所有的應用程式功能都是基於自身供給。

而SOA這個架構雖然有不少原則，但其中最重要的應該就是: 共享的服務、標準化

Micro Service

最後就是近年來頗夯的微服務，概念其實可以參考昨天的KISS，也就是讓應用程式指做一件事情。

這樣會帶來什麼好處呢?

• 為大型系統帶來優勢:
  • 可維護性: 拆散的邏輯讓模組始終有硬邊界(程式本身)可以限縮他不會擴散
  • 可測試性
  • 鬆散耦合: 可以隔離故障，不會導致系統因為單一服務而全部崩潰
• 各自完成工作: 不用太多聚焦於合作，而是可以個自開發。

當然也有相應的缺點

• 要處理服務之間的互動: 包括log、監控。
• 對於特定組間的依賴可能會相對不好引用及維護。

小結

每個架構還是應當考慮他的特性去思考在什麼情境下適用這樣的需求~

比如如果一個開起步，希望MVP可以快速測試市場反應，使用micro service就可能導致花費很多時間處理服務間的互動，或許反倒不易於推出產品。

這時候或許傳統的Monolithic反倒更好一些。

總之老話就是看需求XD

那今天就先這樣啦，雖然還有monorepo沒說到，有機會得話下次再來研究一下!

此文章同步發表於部落格，歡迎來逛逛～

參考資料

Pattern: Monolithic Architecture
Pattern: Micro Services
維基百科
服務導向架構
SOA初級班(3)淺談SOA架構設計